Autopilot APB and XTE precision settings are harmonized to always be the same.

See Send a Route to the Autopilot, the basics. Upon Route activation, OpenCPN sends the ECRMB, ECRMC and ECAPB NMEA sentences to an Auto Pilot, if it is connected to a port, with output activated.

• Implement configurable NMEA Talker ID
• To test that the ECRMB, ECRMC & ECAPB sentences are being sent, simply set up a port with output activated and

Right-click on the chart and select “Navigate to here”, then bring up the Options > Connections > Nmea Debug window and look at the Blue output sentences for ECRMB, ECRMC and ECAPB. Below is one example of output connection settings.

In the example above we have used NavMonPC to read a previously recorded nmea file, and then set up a Virtual Com Port (Com14) which OpenCPN Options > Connections to a Serial Com14 port is then established to read the nmea data stream from NavMonPC.

When you send to the autopilot you should see blue output sentences in the Nmea Debug window, once the Options Menu is closed (very important, because all data is frozen until this menu is closed.) * Another way to test for the EC sentences see “Send to GPS” below.

Dropping them instead.

The feature “Send to GPS”, which appears in the right click menus for waypoints and routes and in the Route Manager, is not linked to connections. The upload port does not even need to appear in the Datastream connections list. Its a completely separate concept. For this reason users must define a separate upload port, that is remembered by OpenCPN. The port can be changed by clicking the button in the Route Manager.

NMEA provides no handshake protocol for Route and Waypoint upload. So, OpenCPN simply sends the Route/WP information out on the port, without having any way to know if there is actually a device connected to the port.

The Garmin protocol does provide handshaking, so OpenCPN can be sure that the information is uploaded correctly. The Garmin protocol will fail if the device is not a Garmin.

In the case of standard NMEA, the indication “Route successfully uploaded” is not very meaningful. You can say that it just means that a port was found, and writing to that port succeeded.

In the case of “hockey puck” GPS receivers, they probably ignore Route and WP uploads, since there is nothing for them to do with this information anyway.

The key to remember is that Route and Waypoint upload process is completely independent of normal running Datastream operation. They are two separate sub-systems.

It does no harm to assign the Datastream GPS port as an output and input device together. Some users might reasonably expect that this would be required for Route and W/P uploads. Most GPS receivers would ignore input sentences other than Route and W/P uploads anyway.

Then in the Chart window we hover over the temporary goto waypoint and right click, then select “Send to GPS (Serial Com 14)” and by quickly looking at the NMEA Debug window (Options > Connections > Check Nmea Debug Window, then be sure to CLOSE the Connections Menu leaving the Nmea Debug Window up, or nothing will happen!). Then you will see the sentences sent. See screenshot below.

• Note the active route above was a 4 point route, but the active leg and active wp was the 3rd point for the above screen.

• Note the screenshot above is for the same Active Route, but the active waypoint is the 2nd point.
• Note: There are many technigues for testing and simulation. Using NavMonPC to read a previously recorded file is one very good way. The other is to use OpenCPN's VDR_pi to read the nmea file, which is in some respects simpler for a new user.

Most, if not all Furuno equipment sending data over UDP is including a binary header at the beginning of the packet payload causing the data not to be parseable as normal NMEA0183 datastream directly. Since the 4.8.2 release, it is possible to configure OpenCPN to handle this problem by editing the opencpn.ini configuration file in the [Settings] section to add the line

 EnableUDPNullHeader=1